<h2>Описание проекта "Банк"</h2>

- [Summary](#summary)
- [Stack](#stack)
- [MVP](#mvp)
- [Бэкенд](#бэкенд)
- [Работа на проекте](#работа-на-проекте)
    - [С чего начинать](#с-чего-начинать)
    - [О таскборде](#о-таскборде)
    - [Как выполнять задачи](#как-выполнять-задачи)
    - [Проверка задач](#проверка-задач)
    - [Требования к коду](#требования-к-коду)
    - [Созвоны по проекту](#созвоны-по-проекту)
    - [Аутентификация](#аутентификация)

### Summary

Реализуем функционал банковского приложения, с базовой структурой БД, можно ознакомится в visual paradigm, в ченджлогах и описании каждого микросервиса
Проект рассчитан на студентов, успешно завершивших этап Pre-Project в Kata Academy.

### Stack

`Java 17`
`Spring Boot 2` - для более быстрой разработки бэка.
`Maven` - как инструмент сборки.
`PostgreSQL` - как БД.
`Spring Data` - для облегчения работы с БД.
`Hibernate` - как ORM.
`Lombok` - чтобы не писать boilerplate-код, используем на проекте [Lombok](https://projectlombok.org/features/all).
`Mapstruct` - для маппинга, [Mapstruct](https://www.baeldung.com/mapstruct).
`Liquibase` - для миграции БД, [Ссылка 1](https://habr.com/ru/post/460377/). [Ссылка 2](https://habr.com/ru/post/460907/).
`Openfeign` - для использования эврика-сервера, и фейн-клиентов для общения между микросервисами.
`Springdoc-openapi-ui` - [Swagger](https://docs.swagger.io/swagger-core/v1.5.0/apidocs/allclasses-noframe.html).
`Junit5` - для тестов.
`Mockito` - для тестов.
`Spring Test` - для интеграционных тестов.
`Spring-security` - для аутентификации и авторизации.
`Docker` - для поднятия контейнеров.
`Postman` - тестирования через запросы.
`Visual paradigm` - для проработки базовый структуры БД и генерации ченджлогов.

### MVP

[MVP](https://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BD%D0%B8%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE_%D0%B6%D0%B8%D0%B7%D0%BD%D0%B5%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1%D0%BD%D1%8B%D0%B9_%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82) - API (полностью описанное в Swagger).
Работать с таким API можно будет через веб-интерфейс Swagger и Postman.

### Бэкенд

Проект основан на микросерверной архитектуре.
А каждый микросервис выстроен по архитектуре REST.
Главный принцип следить, чтобы по логике одинаковые классы лежали в одном пакете.

Слои:
<ul>
<li><code>config</code> конфигурационные классы</li>
<li><code>entity</code> сущности базы данных</li>
<li><code>dto</code> специальные сущности для передачи/получения данных в/с апи</li>
<li><code>repository</code> dao-слой приложения, реализуем в виде интерфейсов Spring Data, имплементирующих JpaRepository.</li>
<li><code>service</code> бизнес-логика приложения, реализуем в виде интерфейсов и имплементирующих их классов.</li>
<li><code>controller</code> обычные и rest-контроллеры приложения.</li>
<li><code>validator</code> валидаторов.</li>
<li><code>exception</code> эксепшнов.</li>
<li><code>handler</code> хэндлеров.</li>
</ul>

## Работа на проекте
### С чего начинать

Доступы. Если ты читаешь это, значит доступ к проекту у тебя уже есть
<ol>
<li>загрузи проект себе в среду разработки</li>
<li>изучи весь проект - начни с pom, properties файлов и конфигурационных классов, так же посмотри visual paradigm</li>
<li>в докере подними БД в командной строке запущенной от имени администратора надо ввести <code>docker run --name postgres -e POSTGRES_PASSWORD=password -e POSTGRES_USER=user -e POSTGRES_DB=postgres -p 5434:5432 -d postgres</code>, где --name имя контейнера, -e POSTGRES_PASSWORD= пароль БД,  POSTGRES_USER= логин БД</li>
<li>так же в БД нужно создать 7 схем: account, anti_fraud, auth, history, profile, transfer, public_bank_information</li>
<li>добейся успешного запуска своего микросервиса</li>
</ol>

### О таскборде

Таск-борд строится по принципу Kanban - он разделён на столбцы, каждый из которых соответствует определённому этапу работы с задачей:
<ul>
<li><code>Backlog</code> задачи на <b>новый функционал</b>, корзина функционала приложения. Здесь можете создавать карточки на таски, которые считаете необходимыми</li>
<li><code>TODO</code> задачи, требующие выполнения</li>
<li><code>In Progress</code> выполняемые в данный момент задачи, обязательно должны иметь исполнителя</li>
<li><code>Cross-review </code> задачи на этапе перекрёстной проверки студентами</li>
<li><code>Final Review</code> задачи на проверке у техлида</li>
<li><code>Closed</code> выполненные задачи</li>
</ul>

У каждой задачи есть теги:
<ul>
<li><code>Feature/Refactor</code> - новый функционал или переработка существующего</li>
<li><code>Bug</code> - таска на исправление бага до или после тестирования</li>
<li><code>Reworking</code> - таска на исправлении замечаний после кросс или файнал ревью</li>
<li><code>Backlog, ToDo, InProgress, CrossReview, FinalReview</code> - этапы прохождения задачи по борде</li>
</ul>

### Как выполнять задачи

<ul>
<li>в графе <code>TODO</code> на таск-борде выбери карточку с задачей и назначь её себе для исполнения</li>
<li>загрузи себе последнюю версию ветки <code>develop</code></li>
<li>создай от <code>develop</code> свою собственную ветку для выполнения взятой задачи. Свою ветку назови так, чтобы было понятно, чему посвящена задача. В начале имени ветки проставь номер задачи с Gitlab. Например, <code>bk-313</code></li>
<li>выполни задачу, обязательно сделай юнит-тесты на методы и, вызови в мавне clean-install, так же после прогона тестов и clean-install, запусти проект и кинь, хотя бы один запрос, если всё ок, залей её в репозиторий проекта, </li>
<li>создай на своей ветке merge request, в теле реквеста укажи <code><i>Closes #здесь-номер-таски"</i></code>. Например, <code>Closes #313</code></li>
<li>перенеси задачу в столбец <code>Cross-review</code></li>
</ul>

### Проверка задач

На этапе кросс-ревью студенты проверяют задачи, выполненные друг другом.
В случае, если к коду есть замечания, проверяющий пишет замечания в мердж реквесте и оставляет комментарий в карточке.
Если к коду претензий нет, проверяющий студент ставит к карточке лайк.

**Каждая карточка (студенческая задача) должна быть проверена как минимум 2 другими студентами и одобрена ими (т.е. собрать не менее 2 лайков).**

Только после этого карточку можно переносить в столбец `Final Review`.

Затем код проверяет техлид (ментор) и в случае обнаружения ошибок ставит тег `Reworking` и переносит её в столбец `InProgress`.
Если всё ок - merge request принимается, ветка студента сливается с основной веткой проекта, а карточка переносится в столбец `Closed`.

### Требования к коду

- сделайте себе понятные никнеймы (имя + фамилия) в Git. Не хочу гадать, кто, где и что писал.
- для каждого класса и (желательно) методов пишите комментарии в формате <b>Javadoc</b>:
    - над классом: что это за класс, зачем нужен. Описывайте поля.
    - над методом: что делает, какие параметры принимает (и что это такое), что возвращает.
    - над приватными методами не нужны комментарии в формате javadoc.
- свободно создавайте собственные вспомогательные классы в пакете Util - типа утилиток для страховки от null и типа того.
- в REST-контроллерах пользоваться аннотациями Swagger - причём как сами контроллеры в целом, так и их отдельные методы. Посмотрите пример в проекте
- на полях сущностей можно и нужно расставлять констрейнты для проверки формата, длины введённых значений, проверки чисел на положительность и т.д.
- пишите Commit message как можно более подробно! На русском языке.
- все контроллеры и их методы нужно сразу описывать аннотациями.

Если в процессе разработки вы пришли к пониманию того, что требуется создать какую-то ещё сущность - создавайте карточку в `Open`, согласуйте ее с тимлидом и вперёд

### Требования к логированию работы:

1. В каждый метод необходимо добавить логирование с описанием произведенной операции на уровне info(только в крайнем случае, чтобы не засорят логи)

2. Если объект не найден, вывести сообщение уровня error ("not found" или "does not exist") с описанием произведенной операции и выбросить EntityNotFoundException.

3. Если бросаете эксепшен, то логируйте с сообщением эксепшена и в уровне error.

### Созвоны по проекту

Созвоны проходят по средам и пятницам в оговорённое время.
Регламент:
- длительность до 15 минут
- формат: доклады по 3 пунктам:
    - что сделано с прошлого созвона
    - какие были/есть трудности
    - что будешь делать до следующего созвона
- техлид (ментор) на созвонах код не ревьюит

Любые другие рабочие созвоны команда проводит без ограничений, т.е. в любое время без участия техлида.
Договаривайтесь сами :)

### Аутентификация

пока используем spring-boot-starter-security
